1. Field of the Invention
This invention relates to the field of distributed computing systems, and object-oriented programming. More specifically, the invention is a method and apparatus for minimizing telecommunications bottle-necks when one network domain communicates with a different type domain.
2. Background
It is desirable that efficient communications be enabled when communicating between heterogeneous computer system domains (for example, between an object-oriented domain and a non-object legacy software domain).
The growth of the internet and large company intranets have generated a need for communications to be put in place between heterogeneous computer systems/networks, such as UNIX.TM. based systems, and Windows based systems, etc. Moreover the adoption within these networks of object-oriented systems creates a new computing domain to add to the mix of different domains which would like to communicate with each other. In object-oriented systems, pointers to object implementations (often called "handles") can be passed from one Client to another Client creating some need to optimize these handles with respect to the communications path they use.
More recently, a new computing paradigm, known as the JAVA.TM. system developed by Sun Microsystems.TM., Inc., is predicated on both a need and an efficient mechanism for passing programs (sometimes called "Applets.TM.") transparently between heterogeneous computer platforms. (UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. JAVA and Sun Microsystems are trademarks of Sun Microsystems, Inc.)
In the past, attempts have been made to minimize the communications traffic between Clients which use handles to point to an object (also called "an object implementation"), especially where these object handles may be passed from one Client to another Client. Solutions to this problem have generally occurred within a single computing domain. That is, solutions to this problem have been found where the computer systems involved in the particular network in question all implemented the same object protocol. For example, U.S. Pat. No. 5,287,507 issued Feb. 15, 1994 ("Hamilton et al") assigned to Sun Microsystems, Inc. and titled "Method and Apparatus for Portable Object Handles that use Local Caches" (and incorporated fully herein by reference) teaches a mechanism whereby a network object handle can be used to reference both a server (the object implementation) and a local cache manager. When the network object handle is sent to another client, the handle is automatically updated to use a cache manager local to the receiving client, or if none is available the handle is updated to point directly to the server rather than communicate through the first client to the server. This process works well to minimize the communications path from the client holding the handle to the server, but it only works in a domain where all computer systems holding the clients and servers are using the same object protocol. Where one has a first domain like this which must communicate across heterogeneous domain boundaries, it is no longer possible to elect to point directly to the server when the server is in one domain and the client is in a second domain which is different from the first domain. This would be like speaking French to a person who only understands German. Thus there usually must be some intermediate mechanism between the calling client and the program in the different domain, wherein the intermediate mechanism can translate between the communications protocol of the calling client and the protocol of the called program.
An attempt to solve this problem, in which heterogeneous domains must communicate with each other, was to install a "gateway server" on one machine, say an object-oriented machine, the gateway server being an object having methods which would convert an object-oriented request from a client using the aforementioned handle, into a message protocol format understood by the second domain. Consider the following example, referring to FIG. 1 which shows a machine A 102 in one computing domain and shows in another domain, machine B 104 and machine C 106. The domain boundary is illustrated by line 120. Machine B 104 and machine C 106 are in an object-oriented domain, whereas machine A 102 is in a second domain. Machine B 104 is shown having a Client B 108 which communicates with a Gateway Server 110 via communication path 112. In this case the Gateway Server 110 is an object which has a method that can convert an object-oriented call into a different format that machine A 102 can understand. This communication is via communication paths 114 and 116. If Client B 108 passes the handle to the Gateway Server 110 to Client C 118 on Machine C 106, and if Machine C 106 has no Gateway Server 110 similar to the one on Machine B 104, then Client C 118 has no choice in communicating to Machine A 102 except that of going through the Gateway server 110 on Machine B 104. Consider now a more specific example, with reference to FIG. 1 which should make this more clear. An NFS server machine A 102 provides access to NFS files. If a Spring object-oriented machine B 104 has a gateway server 110 that converts between NFS operations and Spring file operations, then any program (such as Client B 108 or Client C 118) on Spring machines B 104 and C 106 can use the NFS files exported by machine A 102. ("Spring" is an internal code name used by Sun Microsystems, Inc. to designate a micro-kernel based object-oriented operating system developed in recent years. Spring is described in some detail in U.S. patent application Ser. No. 08/554,794 filed Nov. 7, 1995 now U.S. Pat. No. 5,577,251 (a continuation of Ser. No. 07/995,863 filed Dec. 21, 1992) in group art unit 2317, by Graham Hamilton et al titled "A Method & Apparatus for Subcontracts in Distributed Processing Systems" and which is incorporated fully herein by reference.)
The present invention is a method and apparatus to determine whether it is appropriate, and if so, to automatically interpose a gateway server between an object-oriented program or client and a computer system in another domain, so as to avoid an indirect communications path (path 119 in FIG. 1 for example) through some other machine in its same domain. Consider FIG. 2. If machine C 106 also has a gateway server 122, and if a program (say Client C 118) on machine C 106 obtains a reference to a file from the gateway server 110 on machine B 104, this invention will automatically interpose the gateway server 122 on machine C 106 between the client C 118 and server 110 on machine B 104. The interposed gateway server will convert and forward operation calls on the object reference directly to the NFS server on machine A 102 via communications paths 126 and 128, thereby reducing by half the network traffic required for file access by the program on machine C. If the machine C 106 does not have a gateway server, this invention provides a mechanism to automatically create the desired gateway server on machine C 106. As will be explained in more detail below, the entities designated "Gateway Servers" above may be JAVA classes which are dynamically loaded when needed because some client on a distant machine has passed an object reference to a current machine wherein the front object handle references a machine in another unknown domain.